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Abstract.  This  paper  presents  a  type  system  which  guarantees  that 
well-typed  programs  in  a  procedural  programming  language  satisfy  a 
noninterference  security  property.  With  all  program  inputs  and  outputs 
classified  at  various  security  levels,  the  property  basically  states  that  a 
program  output,  classified  at  some  level,  can  never  change  as  a  result  of 
modifying  only  inputs  classified  at  higher  levels.  Intuitively,  this  means 
the  program  does  not  “leak”  sensitive  data.  The  property  is  similar  to 
a  notion  introduced  years  ago  by  Goguen  and  Meseguer  to  model  secu¬ 
rity  in  multi-level  computer  systems  [7].  We  also  give  an  algorithm  for 
inferring  and  simplifying  principal  types,  which  document  the  security 
requirements  of  programs. 


1  Introduction 

This  paper  presents  a  type  system  for  a  procedural  language  that  guarantees 
that  well-typed  programs  respect  the  security  levels  of  the  variables  they  manip¬ 
ulate.  More  precisely,  it  guarantees  that  well-typed  programs  are  noninterfering , 
which  basically  means  that  high-security  inputs  cannot  affect  low-security  out¬ 
puts.  Goguen  and  Meseguer  introduced  the  idea  of  noninterference  years  ago  as 
a  notion  of  security  for  multi-level  computing  systems  [7];  this  papers  applies 
the  notion  to  programming  languages.  Our  type  soundness  theorem  is  a  proof 
that  every  well-typed  program  has  the  noninterference  property.  The  proof  de¬ 
pends  on  two  lemmas  that,  interestingly,  turn  out  to  be  typing  analogs  of  two 
properties  known  for  years  within  the  security  community  as  the  simple  security 
property  and  the  confinement  property  (also  known  as  the  ^-property).  These 
are  properties  of  the  Bell  and  LaPadula  model,  developed  in  the  early  70’s  as  a 
model  for  multi-level  security  [4]. 

In  an  earlier  work  [17],  we  presented  a  type  system  to  guarantee  noninter¬ 
ference  in  a  simple  imperative  language.  In  this  work,  we  extend  the  analysis  to 
a  language  with  first-order  procedures,  which  can  be  used  polymorphically  with 
respect  to  security  classes.  Also,  we  address  the  type  inference  problem  here. 

We  begin  with  an  overview  of  the  type  system.  Then  we  formally  present 
the  system  and  prove  its  soundness  relative  to  a  standard  natural  semantics. 
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In  Section  6,  we  turn  our  attention  to  type  inference  and  type  simplification. 
Finally,  we  sketch  some  related  efforts  and  some  future  research  directions. 


2  An  Overview  of  the  Type  System 

Noninterference  was  introduced  as  a  model  of  security  for  multi-level  computing 
systems  [7].  The  basic  idea  is  that  a  system  has  users,  some  of  whom  supply 
high-level  inputs  and  others  who  supply  low-level  inputs.  Low-level  users  are 
only  allowed  to  see  low-level  system  outputs.  (For  the  sake  of  simplifying  the 
discussion,  we  shall  consider  only  two  security  levels,  low  and  high.)  Such  a 
system  has  the  noninterference  property  if  no  matter  how  the  high-level  inputs 
change,  the  low-level  system  outputs  remain  the  same. 

The  idea  can  also  be  applied  to  programming  languages.  Intuitively,  the 
notion  is  that  high-level  program  inputs  can  be  altered  without  affecting  any  low- 
level  outputs.  As  a  simple  example,  consider  a  procedure  with  just  two  formal 
parameters  x  and  y: 


proc  P(inout  x  :  low,  inout  y  :  high); 

Here  x  and  y  are  treated  as  variables  with  security  levels  low  and  high  respec¬ 
tively.  Suppose  the  calls  P(u  :  low,v  :  high)  and  P(u  :  low,w  :  high)  terminate 
with  some  final  values  for  u,  v,  and  w.  The  final  values  of  v  and  w  may  differ. 
But  if  P  is  noninterfering,  the  final  value  of  u  will  be  the  same  in  both  cases. 
Our  type  system  guarantees  that  well-typed  programs  are  noninterfering. 

2.1  Types 

The  types  of  the  system  are  stratified  into  three  levels.  There  are  the  r  types, 
which  are  the  security  levels,  the  7r  types,  which  are  the  types  of  expressions  and 
commands,  and  the  p  types,  which  are  the  types  of  phrases.  The  security  levels 
are  assumed  to  be  partially  ordered  by  <.  For  example,  one  might  have  low, 
high,  trusted  and  untrusted  such  that  low  <  high  and  trusted  <  untrusted.  The 
relation  <  is  extended  to  a  subtype  relation  C  over  the  phrase  types. 

Our  phrase  types  are  similar  those  of  Forsythe  [12],  except  that  our  command 
types  are  parameterized.  A  command  type  has  the  form  r  cmd ;  the  intuition 
behind  it  is  that  a  command  c  has  this  type  only  if  every  assignment  in  c  is  to  a 
variable  whose  security  level  is  r  or  higher.  So  if  a  command  has  type  high  cmd, 
then  it  does  not  contain  any  assignments  to  low  variables.  Other  phrase  types  are 
the  types  of  variables,  written  r  var ,  and  the  types  of  acceptors,  written  r  ace. 
A  variable  of  type  r  var  stores  information  whose  security  level  is  r  or  lower.  An 
acceptor  is  a  write-only  variable,  used  to  type  the  out  parameters  of  procedures. 
A  variable  is  implicitly  dereferenced,  so  there  is  a  rule  for  converting  r  var  to  r. 
Likewise,  there  is  a  rule  for  converting  a  variable  type  to  an  acceptor  type,  which 
is  necessary  in  the  left  sides  of  assignments  and  in  procedure  calls  involving 
out  parameters.  The  subtype  relation  is  contravamant  in  both  command  and 
acceptor  types. 


2.2  The  Core  Language  and  Typing  Rules 


The  typed  language  is  a  core  imperative  language  with  procedures;  however, 
procedures  are  not  first  class  values.  Inspired  by  Denning’s  program  certification 
rules  [6],  we  have  developed  typing  rules  that  ensure  noninterference. 

For  instance,  suppose  that  l  and  h  are  variables  and  that  the  identifier  typing 
7  gives  l  type  low  var  and  gives  h  type  high  var.  Then  the  assignment  l  :=  h 
must  be  rejected,  since  a  change  in  the  initial  value  of  h  will  affect  the  final  value 
of  l.  This  is  what  Denning  termed  an  explicit  flow  from  h  to  l.  So  we  introduce 
the  following  typing  rule: 


7  b  e  :  t  acc,  7  h  e'  :  r 
7  \-  e  :=  e'  :  r  cmd 

This  rule  requires  variables  l  and  h  in  our  example  to  agree  on  their  security 
levels.  Since  they  do  not  agree,  even  using  subtyping,  the  assignment  is  rejected. 
On  the  other  hand,  h  :=  l  is  accepted.  Since  low  <  high,  we  can  coerce  the  type 
of  l  from  low  to  high  to  get  agreement,  allowing  the  assignment  to  be  given  type 
high  cmd.  Alternatively,  we  can  coerce  the  type  of  h  from  high  acc  to  low  acc 
to  give  the  assignment  type  low  cmd. 

It  is  worth  pointing  out  that  subtyping  is  neither  covariant  nor  contravari- 
ant  in  variable  types,  because  a  variable  is  both  an  expression  (which  behaves 
covariantly)  and  an  acceptor  (which  behaves  contravariantly).  Hence  low  var  is 
unrelated  to  high  var. 

As  another  example,  suppose  we  try  to  copy  h  to  l  indirectly  as  follows: 

while  h  >  0  do 

l  :=  l  +  1; 

h  :=  h  —  1 

od 

Again  the  final  value  of  l  is  affected  by  the  initial  value  of  h.  This  is  what  Denning 
termed  an  implicit  flow  from  h  to  l.  Thus,  the  typing  rule  for  while  insists  that 
the  guard  and  body  of  the  loop  be  typed  at  the  same  security  level: 

7  h  e  :  r,  7  h  c  :  r  cmd 
7  b  while  e  do  c  :  r  cmd 

Determining  whether  a  given  program  is  noninterfering  is,  of  course,  unde- 
cidable.  As  we  shall  see,  our  type  system  is  a  sound  and  decidable  logic  for 
reasoning  about  the  noninterference  of  a  program.  Therefore,  it  is  necessarily 
incomplete — some  noninterfering  programs  are  rejected  by  the  type  system. 

2.3  Security  Type  Inference 

Type  inference  in  this  setting  attempts  to  prove  that  a  program  is  noninterfering 
and  produces  a  principal  type  that  succinctly  conveys  how  the  program  can  be 
executed  securely.  A  principal  type  is  a  constrained  type  scheme  [13]  with  a 


contramt  set  of  flat  subtype  inequalities  among  security  levels.  Consider,  for 
instance,  the  following  procedure  that  indirectly  copies  x  to  y: 

proc  (in  x,  out  y) 
letvar  a  :=  x  in 
letvar  b  :=  0  in 
while  a  >  0  do 

b  :=  b  +  1; 

a  :=  a  —  1; 
y  :=b 

(The  construct  letvar  x  :=  e  in  c  allocates  a  local  variable  whose  scope  is  c.) 
One  principal  type  for  this  procedure  is 

Va,  [3  with  a  <  [3  .  [3  proc(a,  [3  acc) 

where  a  and  [3  are  type  variables  such  that  a  corresponds  to  the  security  level 
of  x  and  [3  to  the  security  level  of  y.  A  call  to  this  procedure  can  be  executed  se¬ 
curely  provided  that  the  arguments  have  security  levels  that,  when  substituted 
for  the  bound  variables  of  the  type,  satisfy  the  inequality.  The  call  itself  will 
have  type  [3  cmd,  as  conveyed  by  [3  proc.  In  this  sense,  the  procedure  is  poly¬ 
morphic.  The  above  principal  type  can  be  simplified  to  V/3  .  (3  proc(/3,  [3  acc)  due 
to  subtyping  of  procedure  types.  As  a  practical  matter,  it  is  very  important  to 
simplify  the  inferred  principal  types  by  exploiting  the  antisymmetry  of  <  and 
the  monotonicities  of  the  type  constructors.  Type  inference  and  simplification 
are  discussed  in  detail  in  Section  6. 


3  A  Formal 

Treatment  of  the  Type  System 

The  syntax  of  the 

core  imperative  language  is  given  below. 

( Phrase ) 

p  ::=  e  \  c 

( Expr ) 

e  ::=  x  \  n 

|  l  |  e  +  c'  |  e  —  c'  |  e  =  e'  \ 

e  <  e' 

|  proc  (in  x\,  inout  x 2,  out  *3)  c 

( Comm ) 

c  ::=  e  :=  e' 

|  c ;  c'  |  e(ei,e2,e3)  |  while  e  do  c 

if  e  then  c  else  c'  |  letvar  x  :=  e  in  c  | 
letproc  *(in  x\,  inout  X2,  out  *3)  c  in  d 


Meta-variable  x  ranges  over  identifiers,  n  ranges  over  integer  literals  and  l  ranges 
over  locations,  which  are  used  in  our  language  for  input  and  output:  the  initial 
values  of  any  locations  in  a  program  represent  inputs,  and  the  final  values  of  the 
locations  represent  outputs.  (In  addition,  as  will  be  seen  in  the  natural  semantics, 
evaluating  a  letvar  causes  a  new  location  to  be  allocated,  and  later  deallocated.) 
Also,  we  assume  for  simplicity  that  each  procedure  has  exactly  three  parameters 
(one  of  each  kind),  and  we  use  0  for  false  and  1  for  true.  Finally,  a  phrase  is 
closed  if  it  has  no  free  identifiers. 


The  types  of  the  core  language  are  stratified  as  follows: 


r  ::=  s 

7 r  ::=  r  |  r  proc(ri,  T2  var,  73  acc)  |  r  emrf 
p  ::=  7T  |  r  var  |  r  acc 

Meta-variable  s  ranges  over  a  set  of  security  levels,  which  is  partially  ordered 
by  <.  The  rules  of  the  type  system  are  given  in  Figure  1.  We  omit  typing  rules 
for  some  compound  expressions  since  they  are  similar  to  rule  (sum).  Notice  that 
rule  (int)  allows  an  integer  literal  to  be  given  every  security  level.  Intuitively, 
a  value  is  never  intrinsically  sensitive — it  is  sensitive  only  if  it  comes  from  a 
sensitive  location.  Note  also  that  rule  (letproc)  allows  procedures  to  be  used 
polymorphically.  The  remaining  rules  of  the  type  system  constitute  the  subtyping 
logic  and  are  given  in  Figure  2. 

In  the  typing  judgment  A;  7  b  p  :  p,  meta-variable  7  ranges  over  identifier 
typings  and  A  over  location  typings.  An  identifier  typing  is  a  finite  function 
mapping  identifiers  to  types  of  the  form  r,  r  var  or  r  acc;  j(x)  is  the  type 
assigned  to  x  by  7,  and  j[x  :  p]  is  a  modified  identifier  typing  that  assigns  type  p 
to  x  and  assigns  type  j(xr)  to  any  identifier  x'  other  than  x.  A  location  typing  is  a 
finite  function  mapping  locations  to  r  types  with  similar  notational  conventions. 

To  facilitate  the  soundness  proof,  we  introduce  a  syntax-directed  set  of  typing 
rules.  The  rules  of  this  system  are  just  the  rules  of  Figure  1  with  rules  (ident), 
(r-VAl),  (assign),  (if),  and  (while)  replaced  by  their  syntax-directed  coun¬ 
terparts  in  Figure  3.  The  subtyping  rules  in  Figure  2  are  not  included  in  the 
syntax-directed  system.  We  write  judgments  in  the  syntax-directed  system  as 
A;  7  b s  p  :  p.  The  benefit  of  the  syntax-directed  system  is  that  the  last  rule  used 
in  the  derivation  of  a  typing  A;  7  bs  p  :  p  is  uniquely  determined  by  the  form  of 
p  and  of  p.  It  is  also  helpful  in  determining  where  coercions  are  needed  during 
type  inference. 

Next  we  establish  that  the  syntax- directed  system  is  actually  equivalent  to 
our  original  system  with  respect  to  the  7r  types.  First  we  need  two  lemmas: 

Lemma  1.  If  A;  j[x  :  p']  bs  p  :  7r  and  b  p  C  p' ,  then  A;  j[x  :  p\\~s  p  :  ir. 

Lemma  2.  If  A;  7  bs  p  :  7r  and  b  7r  C  7t',  then  A;  7  bs  p  :  7r'. 

Equivalence  is  now  expressed  by  the  following  theorem: 

Theorem  3.  A;  7  b  p  :  7r  iff  A;  7  bs  p  :  it. 

From  now  on,  we  shall  assume  that  all  typing  derivations  are  done  in  the 
syntax-directed  type  system,  and  therefore  shall  take  b  to  mean  bs  . 

4  A  Natural  Semantics 

We  give  a  natural  semantics  for  closed  phrases.  A  closed  phrase  is  evaluated 
relative  to  a  memory  p,  which  is  a  finite  function  from  locations  to  integers.  The 


(ident) 

(var) 

(acceptor) 

(VARLOC) 

(int) 

(r-val) 

(X-val) 

(sum) 

(compose) 

(let  var) 

(assign) 

(TP) 

(while) 

(procedure) 


(apply) 


(letproc) 


A;  7  b  x  :  r  7(1) 

A; 7  b  x  :  r  var  ~f(x) 

A;  7  b  x  :  r  acc  ~f(x) 

A;  7  b  l  :  r  var  A(  Z ) 

A;  7  b  n  \  r 

A;  7  h  f  :  r  var 
A;  7  b  e  :  t 

A;  7  b  e  :  r  var 
A;  7  b  e  :  r  acc 

A;  7  b  e  :  r,  A;  7  b  e  :  i 
A;  7  b  e  +  e'  :  7- 


=  T 

=  t  var 
=  t  acc 

=  r 


r 


A;  7  b  c  :  r  cmd,  A;  7  b  c'  :  r  cmd 
A;  7  b  c§5r'  :  r  cmd 


A;  7  b  e  :  r,  A;  7[r  :  r  par]  bc:r  cmd 
A;  7  b  letvar  1  :  =  e  in  c  :  t'  cmd 


A;  7  b  e  :  r  acc,  \\~/\~c':t 
A;  7  b  e  :=  e'  :  r  cmd 


A;  7  b  e  :  r,  A;  7  b  c  :  r  cmd,  A;  7  b  c  :  r  cmd, 
A;  7  b  if  e  then  c  else  c'  :  7-  cmd 


A;  7  b  e  :  r,  A;  7  b  gg:  r  cmd 
A;  7  b  while  e  do  c  :  7-  cmd 

A;  7[ti  \  t\,X2  :  T2  var,  X3  :  77?.  acc]  bc:r  cmd 
A;  7  b  proc  (in  17,  inout  ite  out  X3)  c  : 

r  proc{  7"i ,  7"2  pr,  77  acc) 

A;  7  b  f  :  r  proc(  ri,  7_2  var,  77  acc), 

A;  7  b  ci  :  77 ,  A;  7  b  C2  :  7’2  var,  A;  7  b  e;,  :  77  acc 
A;  7  b  e(ei,  c 2 ,  63)  :  r  cmd 

A;  7  b  proc  (in  17,  inout  12,  out  X3)  c  :  7r, 

A;  7  b  [proc  (in  17,  inout  X2,  out  X3)  c/r]gf  :  r  cmd 
A;  7  b  letproc  r(in  17,  inout  X2,  out  X3)  c  in  c  :  t  cmd 


Fig.  1.  Rules  of  the  Type  System 


contents  of  a  location  l  £  dom(n)  is  the  integer  /x(l),  and  we  write  fi\l  :=  n] 
for  the  memory  that  assigns  n  to  location  l,  and  to  a  location  V  ^  l\  thus 
/j,[l  :=  n]  is  an  update  of  p,  if  /  £  dorn(n)  and  an  extension  of  p,  if  /  ^  dom(fi). 

Since  expressions  and  commands  are  pure,  our  semantics  uses  p,  b  e  =b  n  for 
the  evaluation  of  an  expression  and  //  b  c  =b  fi'  for  the  evaluation  of  a  command. 
Commands  are  nonexpansive  in  that  dorn(n)  =  dom(n').  We  let  p.  —  l  stand  for 
fi,  with  location  l  removed  from  its  domain. 


(base) 

T  <  T 

b  T  C  t' 

(reflex) 

Ul 

_L 

(tr.ans) 

T  T~ 

in  in 

*r 

in 

( ACC-) 

b  T  C  r' 

b  r'  acc  C  t  acc 

(CMD-) 

b  T  C  T 

b  t'  cmd  C  r  cmd 

(PROC) 

Ul 

_L 

n 

Ul 

"n 

b  7 

C  T 

b  r  proc{  7"i ,  T2  var,  v$ 

acc) 

C  r  proc(r[,  T2  var,  rt  acc) 

(subtype) 

"o. 

Ul 

_L 

_L 

•< 

A;  7  b  p  :  p 

Fig.  2.  Subtyping  rules 

~/(x)  =  T,  T  <  t' 

A;  7  b  x  :  r' 

A;  7  h  e  :  r  var ,  t  <  r' 

A;  7  b  e  :  r' 

A;  7  b  e  :  r  acc,  A;  7  b  e'  :  r,  t'<t 
A;  7  b  e  :=  e'  :  t'  cmd 

A;  7  b  e  :  77  A;  7  b  f  :  r  cmd,  A;  7  b  c'  :  r  cmd,  t'<t 
A;  7  b  if  e  then  c  else  c  :  r7  cmd 

(WIIII.E7)  A;  7  b  e  :  r,  A;  7  b  c  :  r  cmd,  r'  <  r 
A;  7  b  while  e  do  c  :  r7  cmd 

Fig.  3.  Syntax-directed  typing  rules 


(IDENT7) 

(R-VAL7) 

(assign7) 

(IF') 


The  evaluation  rules  are  given  in  Figure  4.  We  writ#  [e' / x\e  to  demote  the 
capture-avoiding  substitution  of  e7  for  all  free  occurrences  of  x  in  e.  Note  the 
use  of  substitution  in  rules  (call),  (bindvar)  and  (bindproc);  this  allows  us 
to  avoid  environments  and  closures  in  the  semantics. 

5  Type  Soundness  as  Noninterference 

In  this  section,  we  establish  the  semantic  soundness  of  our  type  system  by  proving 
a  noninterference  theorem.  Before  proving  soundness,  we  require  some  lemmas 
that  establish  useful  properties  of  the  type  system  and  semantics. 

Lemma 4  (Expression  Substitution).  If  A;  y[x  :  r]  b  p  :  p,  then  A;  7  b 
[n/ x\p  :  p,  and  if  A;  7  b  /  :  p  and  A;  y\x  :  p\  b  p  :  p' ,  then  A;  7  b  [1/ x\p  :  p' . 


(val) 


/(  b  n 


(bindvar) 

(ioop  ) 

(BTNPPROC) 


(contents) 

p 

b 

l  =>■  fi(l)  l  G  dom(p) 

(add) 

If 

b 

e  =?  n,  p  be1  =>  n' 

p 

b 

e  +  e  =$>  n  n 

(sequence) 

p_ 

b 

c  =>  ! u  ,  ft  r  c  =>  ft 

p 

b 

/  ,  // 

c  ;  c  =>  fi 

(branch) 

p_ 

b 

e  =>  1,  h  0  4*  / 

p 

b 

if  e  then  c  else  c7  => 

p_ 

b 

e  =>  0,  (i  b  c7  =>  /W7 

p 

b 

if  e  then  c  else  c'  =>•  //' 

(call) 

p_ 

b 

e  =>■  n,  p  b  [n,l,l'/x i,ia 

p 

F 

(proc  (in  in,  inout  x-2, 

(update) 

p 

b 

e  =$■  n,  l  G  dom(p) 

fi  b  l  :=  e  =>■  ///[I  :=  n] 

(i  h  e  =>  n,  I  is  the  first  location  not  in  dom(p), 
p[l  :=  n]  b  [f/i]c  =>■  fi' 
p  b  letvar  i  :=  e  in  c  //'  —  1 

)i  h  e  0 


//  b  while  e  do  c  =>•  // 

(i  h  e  1,  (i  h  c  =>  /(',  /('  b  while  e  do  c  =>•  p" 
p  b  while  e  do  c  =>•  /(" 

fi  b  [proc  (in  n,  inout  X2,  out  ia)  c/i]c'  =>•  /(' 
fi  b  letproc  i(in  n,  inout  ia,  out  ia)  c  in  #'=>  /// 

Fig.  4.  The  Evaluation  Rules 


Lemma  5  (Simple  Security).  If  X;j  \~  e  :  t,  then  for  every  l  in  e,  A (/)  <  t, 
and  for  every  x  free  in  e,  j(x)  <  r. 

Lemma  6  (Confinement).  If  A  b  c  :  r  cmd,  //  b  c  =>  p! ,  dom(X)  =  dorn(n), 
and  l  is  a  location  assigned  to  in  c,  then  A (/)  >  t  or  p'(l)  =  //(/). 

Now  we  are  ready  to  prove  the  soundness  theorem. 

Theorem  7  (Noninterference).  Suppose 

(а)  A  b  c  :  7T, 

(б)  //  b  c  =>  p' , 

(c)  p  b  c  =>  v' , 

(d)  dom(p)  =  dom{v)  =  dom(X),  and 

(e)  v(l)  =  //(/)  for  all  l  such  that  A (/)  <  r. 

TAett  v'(l)  =  p/(/)  /or  a// 1  such  that  A (/)  <  r. 


In  the  absence  of  procedures,  this  theorem  can  be  proved  directly  [17].  Here, 
however,  we  prove  the  Noninterference  Theorem  as  a  corollary  to  the  following 
theorem,  whose  proof  is  omitted  due  to  space  restrictions. 

Theorem  8.  Suppose 

(a)  A;  [*i  :  n,  .  .  . ,  xk  :  rk\  b  c  :  tt, 

(b)  fi  b  [ni,  .  .  . ,  nk/xi,  .  .  . ,  xk]c  =>  p' , 

(c)  v\~  [nj,  .  .  .,n'k/x  i,  .  .  . ,  xk]c  =>  v' , 

( d )  dom(fi)  =  dom(v)  =  dom(  A), 

(e)  v(l)  =  p(l)  for  all  l  such  that  A (7)  <  t,  and 
(/)  I f  T{  <  t,  for  all  i  such  that  1  <  i  <  k. 

Then  v'{l)  =  pf  if)  for  all  l  such  that  A (7)  <  r. 

It  is  well  known  that  polymorphic  variables  can  easily  break  traditional  forms 
of  type  soundness  [16].  The  same  is  true  of  a  security  type  system.  Giving  a 
variable  polymorphic  type  opens  the  door  to  “laundering” .  It  would  be  possible 
to  store  high  information  and  retrieve  it  as  something  low.  But  soundness  can  also 
break  in  more  subtle  ways  due  to  mutable  objects,  like  variables  and  first-class 
references,  coupled  with  higher-order  polymorphic  procedures.  It  is  interesting 
to  note  that  if  the  core  language  were  extended  with  these  features,  then  existing 
techniques  such  as  weak  types  [14]  or  limiting  polymorphism  to  values  [19]  could 
be  used  to  preserve  soundness. 

6  Type  Inference 

For  the  sake  of  describing  type  inference  in  this  setting,  we  need  to  introduce 
extended  types  that  can  contain  type  variables  (a,  /?, .  .  . )  in  place  of  security 
levels.  We  use  metavariables  r,  7r,  and  p  to  range  over  extended  types.  Also,  we 
use  7  to  range  over  extended  identifier  typings  that  map  identifiers  to  extended 
types;  FTV( j)  gives  the  set  of  free  type  variables  of  j. 

A  type  inference  algorithm  W,  defined  by  cases  on  the  phrases  of  the  lan¬ 
guage,  is  given  in  Figures  5  and  6.  It  takes  as  input  a  location  typing  A,  an 
extended  identifier  typing  j,  a  program  phrase  p,  and  a  set  V  of  type  variables, 
which  represents  the  set  of  “stale”  type  variables;  this  allows  W  to  choose  “fresh” 
type  variables  as  necessary.  If  it  succeeds,  then  it  returns  a  set  of  flat  subtype 
inequalities  C ,  an  extended  type  7r,  and  an  updated  set  V'  of  stale  type  vari¬ 
ables.  Note  that  the  constraint  t  =  r'  abbreviates  the  two  inequalities  t  <  r' 
and  t'  <  t. 

We  now  establish  the  correctness  of  algorithm  W.  An  instantiation  7  is  a 
mapping  from  type  variables  to  (ordinary)  r  types.  It  can  be  applied,  in  the  usual 
way,  to  extended  types,  to  extended  identifier  typings,  and  to  sets  of  inequalities 
among  extended  types. 

Lemma 9.  If  FTV(j)  C  V  and  (C,  tt,  V')  =  W(X,j,p,V)  succeeds,  then  V' 
contains  all  type  variables  in  C',  tt,  and  V . 


W (A,  7,  p,  V)  =  case  p  of 
x  :  case  7(2;)  of 

t  :  ({r  <  a},  a,  V  U  {a})  a  0  V 
r  var  :  ({r  <  a},  a,  V  U  {a})  a  0  V 
default  :  fail 

n  :({},  a,  V  U  {«})  a  0  V 
l  :  ({X(l)  <  a},a,VU{a})  a  g  V 
ei  +  e2  : 

let  (Cu  ?!,¥')  =  W(X,y,ei,V) 
let  (C2,  ?2,V”)  =  W( X,y,e2,V') 
in  (Ci  U  C2  U  {77  =  r2},  77 ,  V") 

proc  (in  x\,  inout  x2,  out  X3)  c  : 

let  (C,  t  cmd,  V’)  =  W (A,  7(27  :  a,x2  :  /?  var,  X3  :  8  acc],  c,VU  {a,  fi ,  5}) 
in  (C,t  proc(a,  /3  var,  8  acc),V')  a,  /3  and  8  0  V 

ci ;  c2  :  let  (Ci ,  77  cmd,  V')  =  W (A,  7,  ci ,  V) 
let  (C2 ,  r2  cmd,  V")  =  W (A,  7,  c2,  V') 
in  (Ci  U  C2  U  {77  =  r2},  77  cmd,  V") 

if  e  then  ci  else  c2  : 

let  (C,  t,  V')  =  W{ X,y,e,V) 

let  (Ci ,  77  cmd,  V")  =  W (A,  7,  ci,Vr) 

let  (C2 ,  r2  cmd,  V'")  =  W (A,  7,  c2,  V") 

in  (C  U  Ci  U  C2  U  {r  =  77  =  r2,  a  <  r},  a  cmd,  V'"  U  {a})  a  0  V'" 

while  e  do  c  : 

let  (C,  r,  V')  =  W{ X,y,e,V) 

let  (C ,  r'  cmd,  V")  =  W (A,  7,  c,  1A') 

in  (C  U  C(  U  jr  =  r' ,  a  <  r},  a  cmd,  V"  U  {a})  a  0  V" 

ei  :=  e2  : 

let  (C,  r' ,  V')  =  W( X,y,e2,V) 
case  ei  of 

x  :  if  7(2)  =  t  var  or  7(2)  =  t  acc  then 

(C  U  {r  =  r' ,  a  <  r'},  a  cmd,  V'  U  {a})  a  0  V' 
else  fail 

l  :  (C  U  {A(!)  =  t' ,  a  <  r'},  a  cmd,  V'  U  {a})  a  0  V' 
default  :  fail 

letvar  x  :=  e  in  c  : 

let  (C,  t,V')  =  W{ X,y,e,V) 

let  (C ,  r'  cmd,  V")  =  W(X,  y\x  :  t  var\,  c,  V') 

in  (CUC1,?  cmd,V") 

letproc  x(in  x\,  inout  x2,  out  X3)  c  in  c'  : 

let  (C,  t,V)  =  W( A,  7,  proc  (in  x\,  inout  x2,  out  X3)  c,  V) 

let  (C ,r  cmd,  V")  =  W(X,  7,  [proc  (in  x\,  inout  x2,  out  X3)  c/x\c',V') 

in  (CUC',f  cmd,  V") 


Fig.  5.  Algorithm  W 


e(ei, e2, e3)  : 

let  (C,  r  proc(ri ,  T2  var,  77  acc),  V')  =  W (A,  f,e,V) 
let  (C",?',C")  =  W(\,T,ei,V') 
let  C"  =  case  e2  of 

x  :  if  7(2;)  =  r"  var  then  C  U  C'  U  {9'  =  9\,9"  =  r2}  else  fail 
1:  CUC"U{?'  =  ?1,X(l)  =  ?2} 
default  :  fail 
in  case  e 3  of 

x  :  if  7(2;)  =  t"  var  or  7(2:)  =  9"  acc  then  (C"  U  {9"  =  73},?  cmd,  V") 
else  fail 

l  :  ( C "  U  {A (1)  =  ts},  9  cmd,  V") 
default  :  fail 


Fig.  6.  Algorithm  W,  continued 


Theorem  10  (Soundness).  Suppose  (C,9,Vr)  =  W(X,y,p,V)  succeeds,  and 
I  is  an  instantiation  such  that  1(C)  is  true,  and  I( 7)  and  1(9)  contain  no  type 
variables.  Then  A;  I(j)  b  p  :  I(tt). 

Proof.  By  induction  on  the  structure  of  p.  We  show  the  most  interesting  case; 
the  other  cases  are  similar  and  follow  straightforwardly  by  induction. 

Suppose  ( C',t  cmd,V ")  =  W(X,  7,  letvar  x  :=  e  in  c,  V),  1(C)  is  true  and 
I(j)  and  I(t)  are  closed.  From  W ,  we  have  C  =  C\  U  C'2  where 

(C1,t',Vi)  =  W(\,y,e,V) 

and 

(C2 ,t  cmd,  V")  =  W(\,  j[x  :t'  var] ,c,Vr)  . 

Let  V  extend  I  so  that  I'(t')  is  closed.  Clearly,  I'(j)  =  I(j)  and  I'(t)  =  1(9) 
since  I'  extends  I  and  I(j)  and  1(9)  are  closed.  Further,  I'(Ci)  is  true  since 
1(C)  is  true.  So  by  induction,  \;I'(]y)  b  e  :  I'(9'),  or  A;  7(7)  b  e  :  I'(9').  Also, 
I'(j[x  :  9'  var])  is  closed  and  I' (C'2)  is  true,  since  1(C)  is  true.  So  by  a  second 
use  of  induction,  \]I'(y\x  :  9'  var])  b  c  :  I' (9)  cmd.  But  I'(y[x  :  9'  var])  = 
I'( l)[x  '■  I'(t')  var],  so  we  have  A;  7(7) [2;  :  I'(9')  var]  b  c  :  1(9 )  cmd.  Therefore, 
by  rule  (letvar),  A;  7(7)  b  letvar  x  :=  e  in  c  :  1(9 )  cmd.  □ 

Theorem  11  (Completeness).  Suppose  A;  7(7)  b  p  :  it  and  FTV( 7)  C  V. 
Then  (C',9,  V')  =  W(X,y,p,  V)  succeeds  and  there  exists  an  instantiation  I'  such 
that  I'  extends  I,  except  on  variables  in  V'  —  V ,  I'(C )  is  true,  and  I' (9)  =  7r. 
Moreover,  if  W(X,y ,  p,V)  does  not  succeed,  then  it  halts  with  fail. 

Proof.  By  induction  on  the  structure  of  p.  We  show  two  of  the  more  interesting 
cases,  while  and  proc;  the  others  are  similar. 

Suppose  A;  7(7)  b  while  e  do  c  :  r'  cmd  and  FTV( 7)  C  V.  Then,  by  rule 
(while'),  there  is  a  type  r  such  that  A;  7(7)  b  e  :  r,  A;  7(7)  b  c  :  r  cmd,  and 
r'  <  r.  So,  by  induction,  (C,  9\,  V')  =  W( X,  7,  e,  V)  succeeds,  V  C  V' ,  and  there 
exists  an  instantiation  I\  such  that  I\  extends  7,  except  on  variables  in  V'  —  V , 


h(C')  is  true  and  Ii(fti)  =  r.  So  7Ti  has  the  form  77  and  I 1(77)  =  r.  And  so  7Ti 
does  not  cause  the  first  pattern  match  to  fail. 

Now  FTV( 7)  C  V' ,  and  I\  and  I  agree  on  all  variables  in  7  since  no  type 
variable  in  V'  —  V  is  a  member  of  7.  So  A;  ^1(7)  b  c  :  r  cmd.  By  induction  again, 
(C",  7r 2,  V")  =  W( A,  7,  c,  V7)  succeeds,  V'  C  V",  and  there  is  an  instantiation  I2 
such  that  I2  extends  I\,  except  on  type  variables  in  V"  —  V' ,  12(C)  is  true  and 
12(^2)  =  t  cmd.  So  7T2  has  the  form  77  cmd  and  12(C)  =  t.  Thus,  the  second 
pattern  match  succeeds  and  so  does  W(X,j,  while  e  do  c,  V),  returning 

(C  U  C  U  {77  =  77,  a  <  77},  a  cmd,  V"  U  {a}) 

where  a  ^  V" .  Now  I2  extends  I,  except  on  variables  in  (V"  —  V')  U  (V1  —  V) 
which  is  V"  —  V  since  V  C  V'  C  V"  by  Lemma  9.  Let  I'  =  I2 [a  :=  r'].  Then  I' 
extends  I  except  on  variables  in  (V"  —  V)  U  {a},  or  (V"  U  {a})  —  V  since  a  ^  V. 

Finally,  we  establish  that  I'(CUC'  U{77  =  77,  a  <  77})  is  true.  By  Lemma  9, 
V’  contains  all  type  variables  in  C  and  in  717,  so  neither  a  nor  any  variable  in 
V"  —  V’  is  a  member  of  C  or  fi.  Thus  I1  and  Ii  agree  on  all  type  variables  in  C 
and  7Ti.  So  I'(C)  is  true  and  I'( 77)  =  r.  Likewise,  by  Lemma  9,  V"  contains  all 
type  variables  in  C"  and  717.  Since  a  ^  V" ,  I'  and  I2  agree  on  all  type  variables 
in  C"  and  717.  So  I' (C)  is  true  and  I' (C)  =  t.  By  the  third  hypothesis  of  rule 
(while'),  I'(a)  <  I'(t i)  and  we’re  done. 

Now  suppose  that 

A;  I(j)  h  proc  (in  x\,  inout  *2,  out  *3)  c  :  r  proc(ri,  77  var ,  77  acc) 

and  FTV( 7)  C  V.  Then  by  rule  (procedure),  we  have 

A;  7(7)[*i  :  ti,  X2  :  77  var ,  *3  :  77  acc]  b  c  :  r  cmd  . 

Let  Ii  =  I[a  :=  77,/?  :=  77,(5  :=  77]  where  a,j3,8  (jL  V.  Since  FTV(j)  C  V, 
then  a,  fi,  and  8  do  not  occur  in  7.  So  X',Ii(fi[xi  :  a,X2  :  fi  var,xs  :  8  acc])  b 
c  :  r  cmd.  Hence,  by  induction,  W( X,j[xi  :  a,  X2  ■  fi  var,xs  :  8  acc\,c,V  U 
{a,fi,8})  succeeds,  returning  (C,  tt,  V'),  V  U{a,fi,8}  C  V' ,  and  there  exists  an 
instantiation  F  such  that  F  extends  I\,  except  on  variables  in  V'  —  (V U{a,  fi,  (5}), 
F (C)  is  true,  and  F(tt)  =  r  cmd.  So  7r  has  the  form  r  cmd  and  F(t)  =  r.  Thus 
the  pattern  match  succeeds  and  so  does 

W(X]  7,  proc  (in  x\,  inout  X2,  out  *3)  c,  V) 

returning  (C',t  proc(a,  fi  var ,  8  acc),  V').  Now  I\  extends  I  except  on  variables 
a,  fi  and  8.  So  F  extends  I  except  on  variables  in  (V1  —  (VU  {a,  fi,  (5}))  U{a,  fi,  8} 
which  is  V'  —  V  since  a,  fi,  and  8  are  in  V'  but  not  V.  □ 

It  follows  from  these  theorems  that  we  can  check  whether  p  is  typable  with 
respect  to  A  and  7  by  first  running  W(  X,  7  ,p,  0),  and,  if  it  succeeds  with  (C,tt,  V), 
then  checking  whether  C  is  satishable  with  respect  to  the  partial  ordering  of 
security  levels.  Checking  the  satish ability  of  a  flat  set  of  subtyping  inequalities 
with  respect  to  a  partial  order  has  been  studied  previously  [15,  18].  It  is  NP- 
complete,  in  general,  but  can  sometimes  be  done  efficiently,  for  example,  if  the 
partial  order  is  a  disjoint  union  of  lattices. 


6.1  Principal  Types 


In  addition  to  checking  typability,  type  inference  gives  us  the  ability  to  com¬ 
pute  principal  types,  that  document  all  possible  types  of  a  program.  We  use 
constrained  quantification  [13]  for  our  principal  types: 


a  ::=  Va  with  C .  7r 

In  such  a  type  scheme,  the  type  variables  d  can  be  instantiated  only  in  ways 
that  satisfy  the  subtype  inequalities  in  C . 

The  instances  of  a  type  scheme  are  defined  as  follows: 

Definitionl2  (Instance).  Vd  with  C .  7r  y  it  if  there  exists  an  instantiation 
I  whose  domain  is  d  such  that  1(C)  is  true  and  b  /(fr)  C  7r.  In  this  case  we  say 
that  7T  is  an  instance  of  Vd  with  C  .  V. 

Definition  13  (Principal  Type),  a  is  a  principal  type  for  p  with  respect  to  A 
and  7  if  for  all  7r,  A;  y  b  p  :  7r  iff  a  y  7r. 

By  the  Soundness  and  Completeness  theorems  above,  we  can  compute  a 
principal  type  for  p  with  respect  to  A  and  y  by  running  (C,  7 r,  V)  =  W(X,  7,  p,  0), 
verifying  that  C  is  satishable,  and  forming  the  type  scheme  Vd  with  C  .  V,  where 
d  contains  all  type  variables  free  in  C  or  V.  (Note  that  the  definition  of  the 
instance  relation  could  in  fact  have  required  that  I(3t)  =  7r;  the  weaker  definition 
was  adopted  to  allow  for  more  type  simplification,  as  we  discuss  below.) 

Here  is  an  example  of  type  inference.  Calling  W  on  the  procedure  given  in 
Section  2.3  produces  the  principal  type 

Va,  'Y,iy,o,e,LX,fi,8,r),6,K,\,l3,£t  with 
( a  <  y,  v  =  o,  e  =  1,  v  <  e,  e  =  (,,  y  <  e,  1  =  p,  6  =  i),  1  <  6,1 
=  0,  8  <  t),  7  =  k,  p  <  7,  k  =  A,  7  <  k,  /?  =  £,  o  <  f3,  8  <  £  J 
.  v  proc(a,  [3  ace) 

Such  a  complex  principal  type  obviously  cannot  serve  as  useful  documentation  to 
a  programmer.  For  this  reason,  it  is  necessary,  as  a  practical  matter,  to  simplify 
the  principal  types  produced  by  W. 

6.2  Type  Simplification 

There  is  a  natural  notion  of  equivalence  on  type  schemes:  two  type  schemes  are 
equivalent  iff  they  have  the  same  set  of  instances.  The  idea  of  type  simplification 
is  to  replace  a  type  scheme  with  a  simpler,  yet  equivalent,  type  scheme.  The  type 
simplifications  considered  in  [13]  can  be  applied  directly  here. 

Often  we  can  make  deductions  about  how  a  type  scheme  Vd  with  C  .  V  can 
be  instantiated.  For  instance,  suppose  that  C  contains  the  inequalities  a  <  [3 
as  well  as  [3  <  a.  Since  <  is  a  partial  order,  any  instantiation  that  satisfies  C 
must  instantiate  a  and  (3  to  the  same  type.  Thus  we  can  unify  a  and  f3.  In 


general,  we  can  collapse  the  strongly-connected  components  of  C .  Performing 
this  simplification  on  the  type  scheme  above  yields  the  simpler  principal  type 

Va,  o,  8,  A,  £  with  {5  <  £,  o  <  A,  A  <  6,  a  <  A}  .  o  proc(a,  £  acc) 

We  can  further  simplify  type  schemes  by  exploiting  the  monotonicities  of 
types.  For  example,  o  proc(a,  £  acc )  is  antimonotonic  in  a;  that  is,  boosting  a 
produces  a  smaller  type.  Since  the  only  constraint  on  a  is  that  a  <  A,  we  can  in¬ 
stantiate  a  to  A,  yielding  a  simpler  principal  type.  Performing  such  monotonicity- 
based  instantiations  repeatedly,  we  finally  obtain  the  principal  type 

V£  .  £  proc (£,  £  acc ) 

which  has  no  constraints  at  all.  With  type  simplification,  principal  types  become 
useful  documentation  of  the  security  requirements  of  programs. 

7  Related  Work  and  Future  Directions 

One  of  the  earliest  efforts  in  the  area  is  Denning’s  lattice  model  of  secure  in¬ 
formation  flow  [5,  6].  Denning  extended  the  work  of  Bell  and  LaPadula  [4] 
by  giving  a  secure-flow  certification  algorithm  for  programs.  This  early  work 
has  been  followed  by  a  variety  of  efforts  dealing  with  secure  information  flow 
[2,8,3,10,11,17], 

Some  of  these  efforts  [8,  10]  have  been  aimed  at  proving  the  soundness  of 
Denning’s  analysis.  These  efforts,  however,  prove  soundness  relative  to  an  in¬ 
strumented  semantics  whose  validity  is  open  to  question.  In  contrast,  we  show 
the  soundness  of  our  analysis  with  respect  to  a  standard  natural  semantics. 

The  work  of  Banatre  et  al.  [3]  is  similar  in  spirit  to  our  work.  They  give  a 
compile-time  algorithm  for  detecting  information  flow  in  sequential  programs, 
and  they  justify  their  algorithm  in  terms  of  a  noninterference  property.  Their 
algorithm  works  by  building  a  final  accessibility  graph  indicating  whether  the 
contents  of  one  variable  at  some  point  in  the  program  can  flow  into  an  instance  of 
a  variable  at  some  other  point.  The  drawback  here  is  that  the  number  of  vertices 
in  the  final  accessibility  graph  is  at  least  linear  in  the  size  of  the  program. 
This  means  that,  unlike  simplified  principal  types,  final  graphs  cannot  serve  as 
practical  program  documentation. 

Palsberg  and  0rbaek  [11]  give  a  type  system  for  trust  analysis  in  the  simply- 
typed  A  calculus  with  a  trust  coercion.  This  (unsafe)  coercion  permits  untrusted 
values  to  be  explicitly  coerced  to  trusted  values.  However,  subject  reduction  is 
the  only  soundness  property  shown  for  their  type  system.  It  is  unclear  what  one 
can  say  about  the  soundness  of  their  system  in  terms  of  secure  information  flow. 
The  trust  coercion  certainly  rules  out  our  noninterference  theorem. 

Another  recent  type-based  approach  is  Abadi’s  work  on  a  version  of  the  pi 
calculus,  called  spi,  extended  to  express  cryptographic  protocols  [1].  Also  related 
is  Necula  and  Lee’s  recent  work  on  proof-carrying  code  [9]. 

In  the  future,  it  would  be  desirable  to  extend  the  core  language  considered 
here  with  a  number  of  important  features,  including  concurrency,  networking, 


and  exception  handling.  The  impact  of  such  features  on  the  noninterference 
property  needs  to  be  investigated. 
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